User interface, system and method for performing a web-based transaction

ABSTRACT

Disclosed is a user interface including an input environment adapted to user inputting of search criteria,
     the search criteria defining a search for at least one entity,   the user interface including a search engine adapted to performing a search on at least two different web-based data sources,   the user interface including means for presenting the search result,   the input environment being adapted to user inputting of an order,   the user interface including a business transaction engine for initialization of a business transaction based on at least one user input of an order.   

     An important feature of the invention is that the user interface features a web-based “search, find, buy” methodology. Hence, the user may specify the desired entity by means of the user-interface, and subsequently be presented with the found entities matching the established search criteria, and then perform a business transaction by applying the same user interface.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No. 10/203,830 filed on Dec. 30, 2002, which is a national phase entry of Application No. PCT/DK2000/00429 filed on Aug. 1, 2000, which claims priority to Denmark Application PA 2000 00222 filed on Feb. 11, 2000, Denmark Application PA 2000 00638 filed on Apr. 14, 2000, and PCT/DK00/00163 filed on Mar. 31, 2000, all of which said applications are herein incorporated by reference in their entirety.

FIELD

The invention relates to a user interface according to claim 1, a method of establishing a transaction according to claim 18, a search configuration editor according to claim 19, a system adapted to searching for entities contained in web-based data sources (DS) according to claim 22, a system, preferably a web-site, according to claim 24, a method of calculating a loan offer intended for financing of specifically selected entities such as cars, boats, computer hardware, etc. by means of a system according to claim 30, a system or web-site according to claim 31, and a communication network-based system for exchanging consumer information between at least one entity provider (SP) and at least one mediator (M) according to claim 33.

BACKGROUND

Internet-based market places and business transactions are well-known within the art.

The market places may generally be categorized into two different categories.

The first category implies an Internet-based market place offering different items or information for sale. The items or information are/is contained within one data source or one type of data source.

Such market places typically offer a high degree of user-friendly access to the items offered for sale due to the fact that the data are contained within one well-known and well-organized data source, e.g. a single database.

The second category of market place implies a central web-based market place. The items available on the market place are contained in a multiple of data bases accessible via specially adapted client software fitting the individual decentral databases. The client software is located at the decentral provider. The data sources are typically maintained by the individual provider and market places of that type benefit from the fact that a high number of items may be accessed via the market place.

A problem with the first type of market place is that the maintenance of the central database is quite time-consuming unless the data are supplied from several item providers in a well-defined format and at well-defined time intervals. Likewise, automated processing of business transactions requires that the transactions are processed in a way which may be understood and implemented by the item provider. In other words, if a large market place of this kind is desired, high quality two-way logistics are required.

A problem with the second type of market place is also that direct communication to and from decentral ERP systems (ERP: Enterprise Resource Planning) requires that certain protocols or ERP systems are applied decentrally. Consequently, providers will need to change the ERP system in order to connect with the market place.

A further problem with the above-mentioned techniques is that the decentral providers have to deal with significant technical burdens if they want to be connected to the market place. Consequently, many companies may never be connected to the market place which reduce the number and types of possible items offered for sale significantly.

It is an object of the invention to provide an Internet-based market place offering a high degree of compatibility to decentral data sources, both with respect to the search for the data and with respect to associated business transactions.

It is a further object of the invention to provide a system which may provide easy access to a huge amount of items and combinations of such items.

SUMMARY

The invention relates to a user interface (UI) according to claim 1,

said user interface comprising an input environment adapted to user inputting of search criteria (SC), said search criteria (SC) defining a search for at least one desired entity said user interface comprising a search engine (SE) adapted to performing a search on at least two different web-based data sources (S1, . . . , Sn) said user interface comprising means for presenting the search result (SR) to the user said input environment being adapted to user inputting of an order (O), said user interface comprising a business transaction engine (BTE) for initialization of a business transaction (BT) based on at least one user input of an order (O).

An important feature of the invention is that the user interface features a web-based “search, find, buy” methodology. Hence, the user may specify the desired entity by means of the user-interface, and subsequently be presented with the found entities matching the established search criteria, and then perform a business transaction by applying the same user interface.

An entity according to the invention may e.g. be an item, a service or a piece of information.

The entity is typically presented to the user as an offer which may e.g. be selected or purchased via financial transactions.

It should be noted that the above-mentioned principles may naturally be supplemented by conventional techniques. Thus, within the scope of the invention, a system of web-based “search-find-buy” may naturally be supplemented by e.g. “search-find” or “just buy”.

According to the invention, means for initialization of said business transaction (BT) on a web-basis includes e.g. HTTP, HTTPS, WML or WAP.

When, as stated in claim 2, said business transaction engine (BTE) comprises means for initialization of said business transaction (BT) on a web basis, a further advantageous embodiment of the invention has been obtained.

A purely, or at least a partly, web-based search-find-buy transaction according to the invention offers a great number of advantages. One advantage is that the user may navigate through several web-sites via only one web-site offering a uniform user interface.

Furthermore, the web-based business transaction method implies the possibility of performing business transactions via order forms already established by the web-based data source owner. Hence, the user-interface may even provide a sale without any mutual commitment between the entity provider and the user interface.

A further advantage is that the user interface may provide entities which may never be established by means of conventional web-sites directly linked to decentral databases. Thus, web-based search-find-buy access to the data sources implies that almost every entity offered for sale on the Internet may be accessed due to the fact that a user interface according to the invention communicates with the data source(s) on the basis of common web-based languages or protocols.

This feature is particularly interesting due to the fact that the web-based interface between the user-interface and the data-source eliminates the problem with conventional systems requiring that the data at the different sources must be represented homogeneously.

According to the invention, means for initialization of said business transaction (BT) on a web-basis includes e.g. HTTP, HTTPS, WML or WAP.

Specifically, means for initialization of said business transaction (BT) on a web-basis includes utilization of HTML-based order forms, where the HTML-based order forms are associated with the web-based data source in question.

Evidently, the automated business transaction engine may be supplemented by other more conventional (manual) business transaction methods.

When, as stated in claim 3, said user interface (UI) comprises means for establishing a search for a combination of at least two entities

said search engine (SE) being adapted to performing a search on at least two different web-based data sources (S1, . . . Sn) for said combination of entities, a further advantageous embodiment of the invention has been obtained.

An important feature of the invention is that the user interface offers the possibility to the user of searching for a combination of entities in the sense that the individual entities of the combinations may be searched for separately in different data sources.

A further very advantageous feature of the invention is that the search for combinations of entities may result in the fact that the individual entities of the combination may be found at different web-based data sources, thus facilitating increased possibility of completion of the user-established search.

When, as stated in claim 4, said user interface comprises means for storing said search criteria (SC) and means for automatically establishing subsequent searches based on the stored search criteria (SC), a further advantageous embodiment of the invention has been obtained.

When, as stated in claim 5, said user interface comprises means for automatically performing a business transaction when entities matching said search criteria (SC) are found, a further advantageous embodiment of the invention has been obtained.

An advantageous feature of the embodiment of the invention is that the result of previous searches may be combined with subsequent searches in a user-friendly way.

When, as stated in claim 6, said user interface (UI) comprises a configuration engine (CE), said configuration engine (CE) comprising a graphical tool for establishing a search for at least one combination (xxxxx, yyyyy) of at least two entities and where said at least one combination may comprise entities found at different data sources (S1-Sn), a further advantageous embodiment of the invention has been obtained.

According to the invention, a configuration engine may advantageously facilitate a quick search for combinations of entities.

One feature of a configuration engine according to the invention is e.g. optimization of the search on the basis of the constraints making up the user query.

Advantageous utilization of the configuration engine offers the possibility of taking mutual dependencies between entities into consideration when establishing a selection. An example of such mutual dependencies to be considered may e.g. be delivery costs to be added to the price of the selected entities, if the individual entities of a selection are delivered by different providers.

Other mutual dependencies may e.g. be if a provider offers a discount if the complete, configured product is bought from only one provider.

Other dependencies to be considered may e.g. be information about advantageous combinations of certain items, i.e. if a user intends to buy a piece of software which is known to be poor choice in relation to the computer he intends to buy. Such information should be submitted to the user by the user interface, thereby increasing the user's opportunity to optimize his product configuration.

Another feature related to such mutual dependencies may e.g. be an automatic initial check of whether the user is trying to configure a number of different items without incorporating a certain item type which is actually mandatory to the configuration.

When, as stated in claim 7, said search engine (SE) is adapted to performing a real-time search on the at least two different web-based data sources (S1, . . . , Sn), a further advantageous embodiment of the invention has been obtained.

An advantageous feature of the embodiment of the invention is that the data found by the real-time search is up-to-date.

When, as stated in claim 8, said search engine (SE) is adapted to performing a search on the at least two different web-based data sources (S1, . . . , Sn) by means of a central database arrangement (CDA), said database arrangement (CDA) being adapted to storing of entities (E) found during previous searches, a further advantageous embodiment of the invention has been obtained.

An advantageous feature of the embodiment of the invention is that the overall search time may be reduced significantly, as the search may be performed by a central database by means of efficient and known database accessing tools.

The database arrangement and maintenance of the data within the database may be performed by means of robots covering certain web-based data sources.

The search itself may be expected to be very fast due to the fact that the search is performed by a central database having low access time.

Moreover, a database offers the possibility of storing the history of the individual entities or groups of entities.

Evidently, the search may be implemented as a combination of real-time and a database search.

When, as stated in claim 9, said previous searches are established according to the pre-established trigger conditions, a further advantageous embodiment of the invention has been obtained.

The trigger conditions may e.g. imply a definition of a time interval or a definition of certain criteria established by a user of the data source owner which may trigger a search.

When, as stated in claim 10, the user interface comprises means for establishing a conditional order (OM), said conditional order (O) automatically initiating a business transaction performed by said business transaction engine (BTE), if certain predefined trigger criteria are met, a further advantageous embodiment of the invention has been obtained.

Accordingly, a business transaction may be performed conditionally, i.e. when a search for a combination of items e.g. having a certain maximum price has been found. Thus, the user may specify some trigger conditions, which may trigger a business transaction when fulfilled. Such trigger conditions may e.g. be; I want to buy if the total price of the configured product is less than a certain amount of money within e.g. a week.

Evidently, the user interface should facilitate graphical means for establishing such trigger conditions.

When, as stated in claim 11, the user interface (UI) comprises means for establishing a loan offer from at least one loan provider, a further advantageous embodiment of the invention has been obtained.

According to the invention, the advantageous provision of loan offers via the user interface facilitates an easy business transaction process, as the search-find-buy procedure may be fully integrated into one single process, even if financing of the intended order has to be established by means of a loan.

When, as stated in claim 12, said loan offer is established on the basis of at least one user-selected entity, a further advantageous embodiment of the invention has been obtained.

The advantageous provision of establishing a loan offer on the basis of one user-selected entity or a combination of entities facilitates a complete match between the needed funds and the entities which the user wants to buy.

When, as stated in claim 13, the user interface (UI) comprises means for accepting a loan offer, a further advantageous embodiment of the invention has been obtained.

When, as stated in claim 14, the user interface (UI) comprises means for initiating an order on the basis of the acceptance of a loan offer, a further advantageous embodiment of the invention has been obtained.

When, as stated in claim 15, the user interface (UI) comprises means for inputting a set of user-described data, and when the user interface comprises means for submitting a subset of said user-described data to at least one loan providers, a further advantageous embodiment of the invention has been obtained.

According to the above-mentioned embodiment of the invention, advantageous business-oriented communication between the user interface and the loan provider has been established. Hence, the user interface may transfer the subset of user-describing data sufficient for the loan provider in order to decide whether the applied loan may be granted, but not enough to identify the user. Then, subsequently, the loan provider may buy the information from the user interface provider, and a deal may be made between the user and the loan provider without any further interference from the user interface provider.

When, as stated in claim 16, said user interface comprises a shopping cart (SC) adapted to storing possible orders, said shopping cart comprising means for selecting at least one of said stored possible orders, and submitting the(se) selected order(s) to an order manager (OM) with the purpose of initiating an order (O), a further advantageous embodiment of the invention has been obtained.

When, as stated in claim 17, said shopping cart (SC) may contain abstract orders (O) which will only be converted into real orders handled by the business transaction engine (BTE) if certain predefined conditions are met, a further advantageous embodiment of the invention has been obtained.

Such trigger conditions may e.g. be time limit, certain user requirements to the desired order which may not presently be met (but may be met in the future) or e.g. a condition specifying a desired order to be handled as a business transaction only if a loan provider agrees to offer a loan for the specific deal.

Moreover, the invention relates to a method of establishing a transaction configured by

at least one set of entities (x,x,x,x,x;y,y,y,y,y) according to claim 18, at least two of said entities being accessible via web-servers (S1, . . . , Sn) at least one set of entities comprising at least two entities accessible via different web-servers, the method comprising the steps of

-   -   establishing at least one query (Qn), said query (Qn) comprising         a set of desired entities (x′,x′,x′,x′,x′; y′,y′,y′,y′,y′)     -   searching in at least two of the web-servers (S1, . . . Sn) for         entities (x, y) matching the desired entities (x′, y′),         presenting at least one of the found of set entities to a user         (U).

According to the invention, complex searches for entities located at different web-based data sources may be performed in such a way that a user may get the impression that the entities are gathered from one virtual source.

Moreover, the invention relates to a search configuration editor according to claim 19, said editor comprising a set of user-selectable identifiers (61, 62, 63, 64, 65, 66), said editor comprising means for combining the selected identifiers in suitable way.

When, as stated in claim 20, said identifiers are searchable by means of search engine (SE) associated with the editor, a further advantageous embodiment of the invention has been obtained.

When, as stated in claim 21, the editor comprises means for associating at least one searchable property (71, 72, 73, 74; 79) with at least one identifier, a further advantageous embodiment of the invention has been obtained.

Moreover, the invention relates to a system adapted to searching for entities contained in web-based data sources (DS) according to claim 22, wherein the system comprises a number of robots established for extraction of data stored in at least two different web-based data sources (DS).

When, as stated in claim 23, said robots are adapted to initiating a business transaction upon request by a user (U), said business transactions being performed by means of communication with at least one of the web-based data sources (DS), a further advantageous embodiment of the invention has been obtained.

Moreover, the invention relates to a system, preferably a web-site, according to claim 24 comprising means (SE) for performing a search for entities, said entities comprising

at least one entity-describing parameter, said system comprising means for facilitating (UI) selection by a user (U) of at least one entity, said system comprising means for automatically transferring the at least one entity-describing parameter or at least a subset of parameters to a calculation model (113), said system comprising means for processing the parameters according to said calculation model and preferably means for displaying the result of the processed parameters to the user (U).

When, as stated in claim 25, said entities are second-hand items or new items, such as cars a further advantageous embodiment of the invention has been obtained.

When, as stated in claim 26, at least one of said entity-describing parameters is price, a further advantageous embodiment of the invention has been obtained.

When, as stated in claim 27, said calculation model is a model for calculation of a loan offer on the basis of at least said price, a further advantageous embodiment of the invention has been obtained.

When, as stated in claim 28, said entity-describing parameters are handed over to different calculation models, a further advantageous embodiment of the invention has been obtained.

When, as stated in claim 29, calculated loan offers and loan offer conditions are displayed to the user, and wherefrom the user may subsequently select one of the offered loans, a further advantageous embodiment of the invention has been obtained.

Moreover, the invention relates to a method of calculating a loan offer intended for financing of specifically selected entities such as cars, boats, computer hardware, etc. by means of a system according to claim 30.

Moreover, the invention relates to a system or web-site according to claim 31 comprising means for receiving entity-describing parameters from e.g. another system or another site,

means for handing said received entity-describing parameters by at least one calculation model, means for processing said entity-describing parameters according to said calculation model, and preferably means for transferring the result of the processed said entity-describing parameters to a user from the other system or site.

When, as stated in claim 32, said calculation model is adapted to calculation of loan offers on the basis of said entity-describing parameters, and any further received parameters, a further advantageous embodiment of the invention has been obtained.

Moreover, the invention relates to a communication network-based system for exchanging consumer information between at least one entity provider (SP) and at least one mediator (M) according to claim 33,

said system comprising at least one application/order form (OF) comprising at least two associated sets of data (AS1, AS2), at least one of said mediator(S) (M) having facilities for receiving at least two of said associated sets of data (AS1, AS2), said system comprising means for transferring at least one of the said associated sets of data from the mediator (M) to the entity provider (SP), said system comprising means for requesting at least one further associated set of data (FS) from said mediator (M), said at least one further set of associated set of data being a subset of said associated sets of data (AS1, AS2), said system comprising means for transferring at least one further associated set (FS) from said mediator (M) to said entity provider (SP) in dependency of said request.

An entity provider may e.g. be bank offering loans or e.g. item providers offering different products ors services for sale.

According to the above-mentioned embodiment of the invention, the mediator, i.e. the owner of a market place may guide a potential customer to the entity which the customer wants to buy.

Subsequently, the mediator may advice the entity provider that someone is interested in buying a certain product or service. The information may be associated with data, the associated sets of data describing the desired entity and the potential customer in part. Then, the provider may decide whether he is interested in dealing with the possible customer, and he may request a complete set of data describing the customer from the mediator.

Evidently, the transfer of the latter part of the associated data may be associated with some kind of payment from the provider to the mediator.

When as stated in claim 34, said system comprises means for assigning an identifier to said associated sets of data in such a way that the mediator (M) may establish the requested associated set of data on the basis of said request, a further advantageous embodiment of the invention has been obtained.

According to the invention, the groupings of associated data may be marked with an identifier, so that the mediator and the provider may communicate over a specific and yet, anonymous potential customer.

The associated data may both describe the potential customer and the entity the which customer wants to buy.

BRIEF DESCRIPTION OF THE FIGURES

The invention will be described below with reference to the drawings of which

FIG. 1 illustrates the basic features of an embodiment of the invention,

FIG. 2 illustrates the principle of performing a combined web-based search and configuration of data allocated in different data sources,

FIG. 3 shows a flow diagram illustrating a search for data allocated in different data sources,

FIG. 4 shows a flow diagram illustrating a configured search for data allocated in different data sources,

FIG. 5 illustrates the basic principles of a configuration editor according to the invention,

FIGS. 6-14 illustrate the use of a configuration editor according to one embodiment of the invention,

FIG. 15 illustrates the filling-in of data in the search profile,

FIG. 16 illustrates a possible presentation of a search result to the invention,

FIG. 17 illustrates the principles of web-based access to a multiple of data sources.

FIG. 18 illustrates a further process flow according to an embodiment of the invention,

FIG. 19 shows the basic principle of accessing data sources according to the invention,

FIG. 20 illustrates the nature of a data source to be accessed according to the invention,

FIG. 21 illustrates the identification and categorization of attributes of a data source according to the invention,

FIGS. 22 a-22 d illustrate access to an individual data source according to an embodiment of the invention,

FIG. 23 illustrates the variation of data sources on the Internet,

FIGS. 24 a-24 d illustrate access to a data source via a form according to one embodiment of the invention,

FIG. 24 e illustrates a detailed method of accessing a data source via a form according to one embodiment of the invention,

FIG. 25 shows the basic principles of the search strategy of the invention as a series of steps to be performed (not necessarily in the same order as shown in the figure),

FIGS. 26 a-26 c show an example of a simple table from an imaginary web site and two different representations of the HTML document creating the table.

DETAILED DESCRIPTION

FIG. 1 illustrates the basic features of an embodiment of the invention.

The illustrated system comprises a user interface UI facilitating communication between a user U and a configuration engine CE and a search engine SE.

Moreover, the user interface UI comprises a graphical editor (not shown) for establishment of a configuration of items or properties located at different web-based data sources S1, S2, S3, . . . , S5. Such an editor should preferably be capable of carrying out a “combined” search for a user-defined combination of entities, even if the individual entities must be found at different data sources.

The illustrated search engine may e.g. work on a realtime and/or database-oriented basis by means of the database search engine DBE and/or the realtime search engine RTE.

The realtime search engine may e.g. work on a realtime basis in the sense that a search for specified entities or items is performed (only) when a user actually searches for the entities or items. Evidently, this method results in quite up-to-date search results.

Another possibility is for the market place to be supported by e.g. a huge amount of robots visiting the data sources e.g. at regular intervals, reading and transferring the complete contents of the search data sources to one central database. Evidently, a database search may be performed at high speed due to the fact that the main search is made by one central (well-organized) data base instead of making a search in a plurality of data sources.

Evidently, the above-mentioned techniques may be combined in many different ways with the purpose of optimizing the search.

Finally, the illustrated user interface comprises a business transaction engine BTE adapted to performing a business transaction. The user interface communicates with the business transactions engine BTE via a shopping cart SC and an order manager OM.

The latter element, the business transaction engine BTE, may technically be regarded as a more or less separate business handling module.

The basic function of the illustrated embodiment of the invention is for a user U to perform a search on the web-based data sources S1, S2, S3, . . . , S5 for certain specified items or item properties defined by the user by means of the user interface UI.

The search may be performed in such a way that individual items or combinations of items may be found by means of the search engine SE.

The found data may subsequently be presented to the user U, and the user may again specify a desired business transaction by means of the shopping cart SC. Subsequently, when activating the shopping cart, the order manager OM may receive the specified, desired business transaction and prepare the initiation of an actual transaction, preferably on a web basis.

The order manager OM may basically function in two different ways.

The first way involves a user U submitting a specific order to the order manager OM by means of the user interface UI. The order manager will then, substantially unconditionally, initiate a business transaction on the basis of the user-specified entities or items.

Payment conditions etc. may typically be controlled by the order manager OM.

The second way involves a user U submitting an abstract, combined order O, meaning that the user U submits an actual valid order, which is only completed if certain conditions are fulfilled. It should be noted that an abstract may in fact sometimes never proceed to the next business transaction step due to the fact that the specified conditions are never met.

When the order is handed over to the business transaction engine BTE, the business transaction engine will in fact ensure that the desired transaction with the respective data sources is converted into an actual buy/sell process. The process is preferably initiated by means of a web-based order form system.

FIG. 2 illustrates the principle of performing the above-mentioned “search-find-buy” user interface UI, including a combined web-based search and configuration of data allocated in different data sources according to one embodiment of the invention.

The user interface comprises means for performing a user query of combinations of items fulfilling the query Qn. The items are located at different web-based data sources. The data sources are generally independent, e.g. different web-sites.

According to the illustrated embodiment, two combinations of items xxxxx, yyyyy fulfill the search criteria.

The two combinations are found by means of a matching Mn performed in order to match the inquiry made by the user with the items actually present in the data sources covered by the search engine SE of the user interface UI.

It should be noted that the user is generally not required to possess any knowledge about the different decentral data sources and that the different data sources are accessed by means of one common interface.

The two combinations may now be presented to the user as a presentation Pn showing the search result.

The user interface comprises means for performing a subsequent business transaction B. The business transaction will typically be made as a selection of the presentation Pn. Hence, the user may e.g. select the combination of items xxxxx and initiate a business transaction by means of the user interface presented to the user.

FIG. 3 illustrates the above-mentioned features of the invention.

Starting with the step SC, a search is initiated by means of a query Q to the search engine SE by means of a suitable user interface.

The search engine compiles the query into a search of several data sources, each data source comprising at least one entity or item.

In the next step, SR returns the result of the search performed by the search engine SE, i.e. the items x2 x 4.

The illustrated items x1, x2, x3 and x4 are found in different data sources (according to the illustrated example).

The search result, i.e. the found items x2 and x4, is then presented to the user.

In the next step, O implies initialization of an order. According to the illustrated embodiment, the user selects the item x2 on the basis of the search result presented by step SR. The order is transmitted to the provider at the corresponding data source by means of the business transaction engine BTE.

The last step, BT, business transaction, implies a “hand-shake” from the provider indicating that a business transaction has been performed.

It should be emphasized that at least two of the involved data sources are web-based, thus offering a high degree of flexibility.

FIG. 4 illustrates a further feature of one embodiment of the invention. The illustrated embodiment is basically based on the aforementioned embodiment, but now it also features a search for combinations of items from different web-based data sources.

Starting with the step CSC, a search is initiated by means of a combined query CQ to the search engine SE by means of a suitable user interface.

The search engine compiles the query into a search of several data sources, each data source comprising at least one item.

In the next step, CSR returns the result of the combined search performed by the search engine SE, i.e. the items x2 x 4.

The search result, i.e. the found items x2 and x4, is then presented to the user.

In the next step, CO implies initialization of a combined order. The user selects, according to the illustrated embodiment, the items x2 and x4 on the basis of the search result presented at step CSR. The combined order is transmitted to the different providers at the corresponding data sources by means of the business transaction engine BTE.

During the last step, CBT combined business transaction, implies a “hand-shake” from the providers indicating that a business transaction has been performed.

It should be emphasized that at least two of the involved data sources are web-based, thus offering a high degree of flexibility.

Evidently, within the scope of the invention, the business transactions engine may sometimes submit combinations of items collected from one data source only. The important feature is that items might be found in different independent data sources.

Turning now to FIG. 5, the principle of an embodiment of a user interface according to the invention is illustrated.

The flow diagram illustrates the interactions between six main elements of the illustrated user interface. The features of each step will be described in detail in the figures below. However, each step will initially be briefly introduced.

The steps include an initial setup of a configuration editor 51.

The setup of the configuration editor implies a selection of possible items, including the definition of the characteristics of the selected items, the items, to be the target of a search, or a calculation determining whether the search items are actually matching the search criteria.

Evidently, the above-mentioned setup of a configuration editor may be omitted within the scope of the invention, when applying one or several predefined search/configuration user interfaces, each adapted to a more or less specifically configurated search.

The next step 52 implies insertion of specific values determining the scope of the search.

If the user prefers to modify the involved items and items after initial insertion of values, he may return to the configuration editor 51 and reconfigure the combination of items to be searched for.

The next step 53 implies a search for the previously specified items.

Subsequently, the next step 54 implies presentation of the found items matching the established search criteria.

Again, the user may return to step 51 or 52 in order to redefine the established configuration or modify the inserted values.

If, on the other hand, the found combination of items fulfills the expectations of the user, the combination may be transferred to the shopping cart 55.

Again, the user may return to steps 51, 52, 53 or 54 in order to redefine the established configuration or modify the inserted values or perform a supplementary search.

In principle, the shopping cart may be adapted to storing several combinations of interest matching different established search criteria, and subsequently, the user may carry out a final selection of the one (or several) combination(s) which he wants to buy.

Finally, when the user has made such a selection, he may place an order on the selected combination and a business transaction may be performed.

The above-mentioned process flow may also be regarded as a search S1, find S2 buy S3 process.

The first step of establishing a search profile by means of the configuration editor 51 will now be explained in detail with reference to FIGS. 6-14.

FIG. 6 illustrates the initial step of entering an opening session by means of a partly predefined combined search.

The illustrated user interface is specifically predefined for PC searches.

Evidently, predefined configurations may be established for other types of standard searches.

Initially, it should be noted that the illustrated configuration setup is only exemplary, and should in no way restrict the scope of the invention.

The opening session features a user interface 60 designed for PC searches.

The interface comprises six item-defining identifiers, processor 61, HD 62, RAM 63, Soundcard 64, Monitor 65 and Any 66.

Evidently, several other setups are possible within the scope of the invention.

Each of the illustrated identifiers 61-66 may subsequently be further refined.

According to the invention, the term “items” may principally imply different definitions depending on the specific application.

According to a preferred terminology, the term “items” implies an object which may be acquired from a provider and which differs from the other items involved in the configuration.

Consequently, “items” may sometimes cover a combination of other (sub) items.

According to the illustrated embodiment, a user activates the identifier, Processor 61, and a new menu appears, as illustrated in FIGS. 7A-7E.

FIG. 7A illustrates the illustrated processor item which may be defined by means of four properties 71-74 which are initially undefined.

In FIG. 7B, the first 71 of these four properties is chosen by means of a curtain 79 to represent the property speed, and in FIG. 7D the property is defined as price. The properties available by means of the curtain are specifically related to the processor item in the sense that the properties are automatically restricted to properties actually searchable in the market place. Evidently, other properties than the illustrated properties may be related to a processor item.

Finally, FIG. 7E illustrates the final configuration setup of the processor item.

FIG. 8 illustrates a UD mark which has been made at the processor identifier 61, indicating that the user has modified the identifier.

Moreover, the user selects the identifier 62 defining the properties of a hard-disc and a new menu appears in FIGS. 9A-9E.

The illustrated sequence shows that the identifying properties are chosen to be disc capacity and price.

Turning now to FIG. 10, a UD mark has been added at the HD identifier 62, indicating that the user has modified the identifier.

Now, the identifier RAM 63 has been chosen by the user and a new menu appears as illustrated in FIGS. 11A-11C.

It should be noted that the initial menu in FIG. 11A contains a predefined setup of properties, i.e. capacity and price. Evidently, if a configuration editor should be predefined for PC-search purposes, such default setups should preferably be made for each chosen identifier 61-65 in order to facilitate a high degree of user friendliness.

The illustrated flow shows that the user adds the Access time property to the property settings.

The next step of dealing with the identifier Any 66 is a little more complicated. Nevertheless, it reveals a remarkable feature of the embodiment of the invention.

This feature will be described with reference to FIGS. 12, 13A and 13B.

As indicated, the identifier Any 66, which may naturally comprise several identifiers, may be applied for combining the search for the computer hardware with a softer search for a piece of furniture to be used together with the equipment as comprised by the identifiers 61-65.

When selecting the identifier 66, as new menu appears which is slightly different from the aforementioned menus.

The menu appearing as illustrated in FIG. 13A comprises a facility adapted to choosing an item from a selection of predefined possible items. The illustrated item, monitor furniture, is selected by means of tree structure, each node of said tree structure defining the desired items of a group of items.

Evidently, many other possible selecting tools may be applied according to the invention.

The selected item, monitor furniture, offers the possibility of attaching four different search properties to the item, Manufacturer, Color, New/2^(nd) hand and Price.

According to the illustrated setup of FIG. 13B, the user chooses the last three properties Color, New/2^(nd) hand and Price.

Now, as illustrated in FIG. 14, the configuration editor has been designed by the user to comprise the desired searches.

It should be noted that especially the last feature, i.e. adding of items not closely related to other items, offers the possibility of very strong and user-friendly data acquisition. This is due to the fact that the underlying data sources of the configuration editor are web-based and do therefore offer a considerable amount of information and several items, i.e. 2^(nd) hand items, not usually for sale in large-scale market places.

When the user is ready for the search, he may select the Next button in order to insert values according to step 52 of FIG. 5.

Turning now to FIG. 15, the user has inserted the value 1000 MHz as a property search criteria with respect to the processor. Moreover, the user has inputted the value 20 Gbytes as the minimum capacity of the hard-disc, 128 Mbytes as the minimum RAM storage capacity and the monitor furniture has been specified as white and potentially a 2^(nd) hand offer.

The inserted values may be regarded as entity-describing parameters.

Now, the user has the option to search for the items individually by means of the Search Components button 151 or choose the search configuration button 152.

The Search Configuration button 152 has been specified by the value $1500 inserted in the configuration area.

According to the illustrated flow, the user now selects the latter button, thus initiating a search for the components in the left hand area, restricted by the inserted values AND the inserted value inserted in the right hand area, determining the total maximum price for the configured PC and the furniture.

FIG. 16A illustrates step 54 of FIG. 5, namely a listing of the found configurations matching the specified search.

According to the illustrated search, three configurations fulfilling the search criteria have been found and they are displayed as Matching configurations 1, 2 and 3.

As illustrated, the user now selects the configuration and combination of items of actual interest.

It should be noted that the user may not necessarily gain knowledge of how and where the different items may be offered for sale (superfluous to the user). It should moreover be noted that the user has the possibility of returning to the previous display setups by means of the buttons 161 and 162, if so desired.

The selected configuration is now transferred to the shopping cart. However, it should be noted that the user may still perform new searches and modify the identifiers, if so desired.

Finally, the user may choose one or several configurations of items (only one is shown) and perform a business transaction by means of the button 165.

If, on the other hand, no matching configurations of items were found, a business transactions may still be initiated by transferring the established search criteria to the shopping cart (not shown) and specifying the conditions under which such business transaction may actually be performed.

Such condition may e.g. imply a transfer of the inserted values of FIG. 15 to the shopping cart, specifying another total price for the complete configuration, e.g. $1100 as a trigger condition for a business transaction.

Further trigger conditions may e.g. be time limit, e.g. a week, within which the buying order is valid.

Consequently, a shopping cart according to the invention may be applied both for a specific order and an abstract order.

A further attractive possibility may be exploited by a user by activating a button 165. Activation of each of the applied buttons 165 will imply a transfer of information describing the associated configuration (at least the total price) and a loan offering engine (not shown). The loan offering engine may be adapted to presenting a number of loan offers based on supplementary personal information provided by the user and information describing the configuration associated with the activated button 165. The loan offering engine may e.g. be partly administered by a bank.

If the user chooses to accept a loan offer, he may then accept the loan offer and the information may be returned by the loan offering engine in such way that it may be validly (and securely) submitted to the item provider offering the desired item(s) for sale, and a business transaction may instantly be processed.

FIG. 17 illustrates a number of data sources attached to a user interface UI according to the invention.

At least two of the involved data bases DB are indirectly accessible via a web-platform WP. In this respect, a data source is regarded as a database and an associated web-platform.

Evidently, the user interface may be supplemented by other data bases DB directly accessible e.g. by means of agents performing data retrieval on an ODBC or SQL basis.

Nevertheless, a main feature of the invention is still that many data sources are made accessible via a web-platform. This is due to the fact that the web-platform represents a uniform and well-distributed data exchange interface between the data bases DB and the user interface UI. Hence, a data source owner may easily attach his data source to the market place (represented by the user interface UI) in an easy and relatively secure way due to the fact the web-platform is accepted by the user interface UI. Moreover, most companies may reuse the already established web-based homepages as links to the market-place, thereby reusing both their product representation and their already established web-based business transaction interface.

Moreover, when seen from the point of view of a technician, the system benefits from the fact that the data from the data sources are all represented quite homogeneously in the sense that interfacing is basically established by the same protocol techniques. On the other hand, it should be noted that implementation of the web-platform WP may differ significantly from data source DB to data source DB, thereby shifting the burden of establishing an interface between the web-based data sources from the data source provider to the user interface UI provider.

It should also be noted that the establishment of a user interface capable of communicating with web-based data sources creates a mutual independence between the user interface provider and the data source provider.

A purely, or at least a partly, web-based search-find-buy transaction according to the invention offers a great number of advantageous. One advantage is that the user may navigate through several web-sites via only one web-site offering a uniform user interface.

Furthermore, the web-based business transaction method implies the possibility of performing business transactions via an order form already established by the web-based data source owner. Hence, the user-interface may even provide a sale without any mutual commitment between the entity provider and the user interface.

A further advantage is that the user interface may provide entities which may never be established by means of conventional web-sites directly liked to de-central databases. Thus, the web-based search-find-buy access to the data sources implies that almost every entity offered for sale at the Internet may be accessed due to the fact that a user interface according to the invention communicates with the data source(s) on the basis of common web-based languages or protocols.

This feature is particularly interesting due to the fact that the web-based interface between the user-interface and the data-source eliminates the problem of conventional systems requiring data at the different sources to be represented homogeneously.

According to the invention, means for initialization of said business transaction (BT) on a web-basis includes e.g. HTTP, HTTPS, WML or WAP.

Specifically, means for initialization of said business transaction (BT) on a web-basis includes utilization of HTML-based order forms, where the HTML-based order forms are associated with the web-based data source in question.

Evidently, the automated business transaction engine may be supplemented by other more conventional (manual) business transaction methods.

Turning now to FIG. 18, a further process flow according to an embodiment of the invention has been illustrated. The process flow basically comprises five process steps, 111, 112, 113, 114 and 115.

Process step 111 of one or a combination of entities (such as items) is found by means of a suitable user interface. A suitable user interface may e.g. be an interface adapted to search at least one data source for certain user-defined entities, such as items, services, travels, cars, books, apartments, etc. automatically or upon request by a user. The user interface should preferably comprise a user interface accessible to a user U via the web.

The entity(ies) would typically be found by means of more or less intelligent search tools. The search tool submits one or several entities as a response to a user query. The submitted entities comprise a number of entity-describing parameters EP, such as brand, type, age, price, etc, if it is a car. The user may then acquire a loan offer matching the found entity, e.g. by selecting a button 165 associated with the found entity.

Evidently, such offers may also be provided automatically once the entity has been selected by the user and handed over to the order manager OM.

In the next step 112, a suitable number of the entity-describing parameters (properties) is inputted in one or more calculation models and the user inputs certain personal information (if required). The calculations are subsequently presented to the user according to suitable guidelines on the basis of the parameters and the additional personal information, if any.

It should be noted that the previous search for the entity, step 111, may be executed on another web-site (i.e. another market place), and subsequently, the entity-describing parameters may be handed over to another site for subsequent processing of step 112 and any further subsequent steps.

All necessary entity describing parameters are handed over to step 112 and the user may input certain parameters, such as payment, tax rate, etc.

Subsequently, step 113 may calculate a loan offer matching the desired entities. The calculation may be performed at a user interface server or the data may be submitted for more or less camouflaged external processing, i.e. transferred to an bank server.

Another way of external processing may e.g. be an “anonymous” request made by the user interface UI server to a bank. The request should preferably be made in such a way the request contains only customer-describing parameters only and no customer-identifying parameters.

In this way, the bank may keep the calculation model secret, and the request by the user may be kept anonymous until he is absolutely sure that he will actually apply for a loan.

If the calculation of a loan offer is to be made at the user interface server, the calculation model should be integrated in the portal.

In step 114, the user may actually apply for a loan based on one or several offers from different loan providers.

The application is processed in step 115, and the loan may be granted or refused.

If the loan is granted, the user interface should preferably facilitate a business transaction upon grant of the loan. Thus, the user should preferably be pipelined directly to the a business transaction, where payment for the selected entities is actually made to the entity provider more or less directly by the loan provider.

The loan provision may thus be integrated in the complete business transaction according to the embodiment of the invention.

Turning now to FIGS. 19-26, the basic principles of possible access to web-based data sources by means of a search are illustrated. Evidently, a search engine according to the invention may be established in other ways than that illustrated by the embodiments.

FIG. 19 shows the basic principle of accessing data sources according to one embodiment of the invention. Evidently, numerous other methods are applicable within the scope of the invention.

The illustrated system is run by standard computers e.g. mutually connected via the Internet.

The illustrated system comprises a plurality of data sources DS. The data sources DS are generally independent, at least with respect to the form according to which data is stored in the individual data sources. Typically, there will no common access key to the data elements of the data source.

According to the invention, a large number of independent web-sites may be accessed by means of the same retrieving profile.

An typical independent data source according to the invention may be understood as a data source being established independently of the retrieving profile RP. In other words, when established the retrieving profile no help for automatically interpretation should be expected from the data source at all.

An important characteristic of an independent data source is that an entity is retrieved from the data source without the transferring of unique ID coding. The identification of the individual transferred entities is based solely or primarily on the basis of the combinations of the attributes comprised in the retrieved entity and/or the environment from which the entity is retrieved due to the fact that no unambiguous key related to the entity should be expected from the data source.

Hence, according to one teaching of the invention, the relaxed requirements with respect to syntax and representation of the entities of a data source facilitate access and roboting of data sources which, until now, have been accessible only via manual search.

An example of representative data sources of the above-mentioned kind may e.g. be a web site offering second-hand cars. Each web-site is typically owned by independent car dealers offering different car models from different years, different prices, etc.

An important feature of the exemplified type of data source is that a car of a certain type, model and year may be offered for sale at different prices by the car dealer due to e.g. different price policies and different conditions of sale. This aspect illustrates that the mere identification of a car model at a web-site only reveals very little information about the specific car offered for sale. In the light of that explanation, each second-hand car offered may be regarded as unique.

Other examples of such data sources may e.g. be job-advertising, loan offers, odds, offers, news, etc.

Evidently, data sources according to the invention may comprise combinations of new and second-hand objects or even other types of objects.

The nature of a data source according to the invention will be described in detail with reference to FIG. 20.

Returning now to FIG. 19, each data source DS may be visited by a user U via a retrieving profile RP. The illustrated embodiment of the invention includes a database DB which may be accessed for reading and writing purposes via the retrieving profile.

Each data source may be visited via the retrieving profile RP if a user U addresses a query at the involved data sources DS. The retrieving profile RP may be implemented in several different ways within the scope of the invention.

According to the illustrated embodiment, the retrieving profile RP comprises robots each accessing the different data sources DS and retrieves information about a certain domain of entities. An example of such a domain may e.g. be the above-mentioned domain of cars offered for sale. The retrieved information may be interpreted by the robot and the information stored wholly or partly in the database DB in an easy searchable format. Evidently, the database may link the user to the original data sources if so desired. The up-date rate of the robot may be established according to several different trigger criteria. One of the criteria may be a robot dedicated to a certain data source and adapted to visiting the data source at certain time intervals.

According to the illustrated embodiment of the invention, a query may be carried out by means of a search in the database DB instead of visiting the data sources.

Hence, the function of the retrieving profile is to guide one query or a set of queries in such a way that each entity matching the user query may be presented to the user.

Another possible implementation of the retrieving profile (not illustrated) may be an encapsulation of each or some the data sources in such a way the query is suitably directed at the contents of a data source. The most important function of such an encapsulation contained in the retrieving profile is to avoid unnecessary searching in parts of the data source which have already been identified as irrelevant to the specific user query.

Returning now to the illustrated embodiment, an example of a query established by the user U may be a query for a car of the type “Porsche” less than three years old and offered at a price interval of $10,000 to $11,000. The query may typically be invoked by filling in a form offered to the user U at a web based market place controlling or facilitating the illustrated system. The retrieving profile RP may subsequently perform a search in the database DB without consulting the data sources and the result may be listed to the user at the provider web-site. A user may subsequently choose to access the original data sources, e.g. the web-site, in order to obtain additional information, such as a picture or further description of the located cars via a link associated with the car in the result list.

The retrieving profile RP may be regarded as a program structure established in order to match a user query to all data sources inferred by a user request.

FIG. 20 illustrates the complex nature of a data source to be accessed according to the invention. The illustrated data source DS has a data structure which is initially unrevealed and incompatible with the access tools of the retrieving profile RP associated with the specific data source DS.

Initially, the data source DS regards the automatic retrieving profile as a chaotic plurality of information. According to the illustrated embodiment, the character-based information of the data source DS has been converted into a number of attributes of identified text strings. Evidently, attributes may be encoded and decoded in various formats such as character based formats, image based formats and active content formats, such as Java applet, JavaScript application or VB script application.

The text strings may e.g. be a mix of text strings identifying car names, model names, numbers, etc.

Subsequently, the data source must be evaluated and interpreted in order to facilitate access to hidden information by the retrieving profile RP.

FIG. 21 illustrates identification and categorization of attributes of a data source according to the invention.

The attributes, i.e. the text strings of the data source, may subsequently be interpreted and combined into so-called entities of associated attributes ASA. The associated attributes may be established so as to comprise certain predefined types of attributes, i.e. categorized attributes.

An example of an entity is a car entity comprising the categorized attributes CA “Trabant”, '88 and $100,000 where the first attribute of the category is car model, the second attribute of the category is manufacturing year and the third attribute of the category is the price.

Each entity is established as a set of associated attributes ASA and the irrelevant attributes are filtered away.

Evidently, the establishment of entities of associated attributes may be performed in several different ways, and more or less automatically, within the scope of the invention. It should be noted that the preferred embodiment of the invention implies a completely automatic establishment of as many robots as possible.

Subsequently, the identified entities may be copied into the central database DB means in such a way that the retrieving profile initially performs a query in the database instead of visiting every involved data source DS and lists the results to the user according to a predefined listing format. This feature ensures quick access to the search result. If the user U requires additional information, this information may be obtained by means of a link contained in the above-mentioned result list.

When the entities have been copied to the database and associated with the retrieving profile, further information is added to the retrieving profile in the form of a robot adapted to the data structure of the specific data source. This robot is associated with the retrieving profile in order to visit the data source according to certain trigger criteria and to reevaluate the data source in order determine whether the contents of the data source have been changed. Hence, the robot will access the data source e.g. at certain intervals and update the contents of the database if changes have occurred. Such an automatically handled change may take place if e.g. one entity has been removed from the data source and replaced by two other entities where the removed entity represents a sold car and the two new entities represent cars introduced for sale.

Such a change observed by the robot should of course be reflected in the database, as the sold car has to be removed and the two cars be added to the database in order to reflect the state of the data source when the data source is visited.

A change may likewise be stored and registered for statistic purposes in another database.

If, on the other hand, the data structure of the data source has changed in such a way that the robot is no longer able to extract the correct information, an error is reported to the retrieving profile. Such an error results in the establishment of a new robot fitting the new structure of the data source.

It should be noted that each data-source typically requires a dedicated robot.

FIGS. 22 a to 22 d illustrate some important features of the invention with respect to the above-mentioned retrieving profile RP. It should be noted that the two different ways of operating the retrieving profile are only examples and do in no way restrict the operation of retrieving profiles to only the illustrated two. The use of the retrieving profiles implies several possible modifications within the teaching of the invention.

The circles involve a system operation or system source, the squares involve an independent data source and the hexagonals involve a user operation such as a query.

FIGS. 22 a and 22 b illustrate the operation of a retrieving profile if a method according to the invention involves the utilization of a central database.

According to the first embodiment, the retrieval/analysis of data from a data source DS and the retrieval of data from the data source performed by a user via a user query are basically two different processes (operations).

FIG. 22 a illustrates a first embodiment according to which the system analyzes and retrieves information from a single data source basically independently of any user query.

The operation may be as follows: A data source DS is visited as a result of the fulfillment of certain trigger criteria TC. Visiting the data source DS is established via the retrieving profile RP. No structural information about the data source will be found if the data source has not been visited before. Such a situation triggers an initial analysis of the data source. The extracted entities are stored in the central database DB according to predefined storing criteria and a robot is established for later access to the data source according to the identified data structure of the source. The robot will be contained in the retrieving profile.

In another scenario, the data source will be accessed directly by the already established dedicated robot if the retrieving profile related to the specific data source contains information determining the data structure of the data source.

The retrieving profile is subsequently modified if minor changes in the data structure of the data source are detected insofar the existing robot may be suitably modified. If not, an error flag is raised and a new robot has to be included in the retrieving profile.

Evidently, several different trigger criteria may be established within the scope of the invention.

FIG. 22 b illustrates the function of the system from another point of view. The figure illustrates the invoked procedures if a user query Uq is established according to the illustrated embodiment of the invention. A user query Uq is entered via e.g. a user query form, e.g. a web site. The user query Uq contains different entries specifying the desired information within a certain domain. This query invokes a search in the central database DB containing a “mirror” of all entities identified in the searched data sources as described above.

The search may be performed in a quick manner due to the fact that the entities are contained in a database having a high degree of order.

The result of the search is returned to the user in a predefined way and the user may typically be guided to the original data sources DS by means of a link incorporated in the result list if the user so desires. This option is illustrated by the dotted lines.

It should be noted that the procedure of traversing through the involved data sources and the establishment of a central database according to the illustrated embodiment are separate functions and principally non-correlated with the search performed in the database upon request by a user query.

The basic understanding of the application is that the maintenance of the system is separated from the utilization of the system.

Turning now to FIGS. 22 c and 22 d a further embodiment of the invention has been disclosed. This embodiment implies a higher degree of correlation between the maintenance and the facilitated queries.

FIG. 22 c illustrates the initial establishment of a retrieving profile RP fitting a specific data source DS. The establishment is triggered by certain trigger conditions.

The retrieving profile RP will be updated when the data source DS has been analyzed and the data structure of the data source has been identified. The retrieving profile RP is established as an encapsulation of the corresponding data source DS. However, in this case no data will be stored in a database. Instead, the retrieving profile RP may be regarded as a robot dedicated to a specific data source, and the robot may be triggered by a user query.

FIG. 22 d illustrates a user request Uq triggering access to some data sources DS containing the entities matching the user query.

When the desired entities have been retrieved, the result is returned to the user and the retrieving profile is updated if relevant changes in the data structure have occurred.

The retrieving profile RP of the illustrated embodiment contains information matching the user query Uq to the already analyzed contents of the data sources. Such a retrieving profile requires a high degree of refinement in order to obtain a real-time search in the data sources. It should be noted that access to the individual data sources may be quite time-consuming. Hence, in order to reduce the query response time, the retrieving profile should contain quite a lot information about the entities and the grouping of entities in the individual data sources.

It is to be noted that local query tools may be used for both real-time and full extraction.

Finally, it should be emphasized that the above-mentioned access philosophies may be combined if so desired.

In order to explain the quite complex situation of visiting independent data sources, a further detailed explanation will be provided below.

FIG. 23 illustrates the variation of data sources on the Internet. Specifically, the example illustrates that several different access methods have to be established when dealing with different types of data sources in the form of web-sites.

FIG. 23 illustrates three different independent data sources DS1, DS2 and DS3.

Each data source forms an Internet web-site open to public access.

The first data source comprises a number of documents D accessible via a local query form LQF1. The form comprises a number of input fields, IQE, by which a user may input certain types of entries in order to conduct a search. Traditionally, such entries may be established via dedicated input fields. Evidently, several other input forms may be applicable.

The result of a query is monitored by a number of result lists RL and each list comprises a maximum number of hits. At some sites, such list are truncated if the number of hits exceed a certain number and data is lost.

Another data source DS2 comprises a web site of two documents. The site offers no form facilities and the information is presented by means of simple listing or even as pure text documents.

A third data source DS3 also comprises a number of documents D which may be queried by means of a local query form LQF3. The form comprises a number of input fields by which a user may input certain types of entries in order to conduct a search.

As for the data source, DS1, the result of a query is monitored by a number of result lists RL and each list comprises a maximum number of hits. These lists must be scrolled sequentially in order to access the query hits. The illustrated result lists may each comprise a maximum number of hits which is greater than the result lists of DS1.

It may easily be understood that automatic access to the entities is very difficult for the different data sources for different reasons.

Hence, if the data source DS1 is queried by the retrieving profile and the resulting hits of the query exceed the maximum number of hits presentable in the result list, a complicated situation has arisen.

Moreover, data source DS2 comprises more or less chaotic information, and an intelligent method must be applied in order to establish and interpret the relevant information of the site.

The third data source DS3 looks a little like DS1 but differs significantly since the result list allows a greater number of hits in the result lists RL compared with that of the result list of DS1.

Moreover, the possible query entries of LQF3 differ from the possible query entries of LQF1.

According to the invention, the data sources are accessed via a user query form UQF comprising a fill-in form suitable for all possible types and combinations of queries.

The illustrated user query form covers possible queries of local query forms and a further possible query fields addressing added information obtained by the predescribed classification.

A query type may e.g. be a car model, price, year, etc.

Typically, a certain minimum of information must be present at the web-site, such as price and car model. Such minimum criteria may be contained in the retrieving profile.

Turning now to FIG. 24 e, a possible breakdown of a data source according to an embodiment of the invention will be described with reference to a binary query tree QT.

The illustrated method may be used for both total extraction from a data source or a direct user request.

The query tree QT illustrates how a local query form may be controlled to present a number of partial result lists representative of the total number of hits, and thus overcoming the problem of truncated result lists.

The illustrated example comprises a very simple data source, e.g. a web site offering second-hand cars.

The data source may be accessed through a query form having two possible query types; car model and year. The possible car models are Audi, BMW and Ford. The possible years are from 1980 to 2000.

According to a first entry, the data source is queried for an Audi: car model, C1, and within the possible years of 1980 to 2000.

The result of the initial query is 42 hits, but the present site truncates the result list to 20 hits, i.e. 20 cars.

Accordingly, the initial query is automatically divided into two child nodes, C1&1980-1989 and C1&1990-2000. These queries should result in 29 and 3 hits respectively, i.e. too many hits in the first node.

Accordingly, the first node binary is divided into two queries C1&1980-1984 and C1&1985-1989. The number of results corresponding to each query is now 17 and 12, respectively.

Consequently, the initial query of C1&1980-2000 has now been fractioned into three queries C1&1980-1984, C1&1985-1989 and C1&1990-2000 providing the desired result in a result list having less than 20 true hits which are not truncated.

It should be noted that a complete query tree according to an embodiment of the invention may typically be stored in the retrieving profile once a data source has been accessed. Later, when the data source is accessed again, the data of the data source may be retrieved by means of the stored query combination. If, on the other hand, the contents of the data source have changed by removal or addition of entities, the stored query combination is no longer valid, and the query combination has to be recombined. This recombination is facilitated by storing the entire tree due to the fact that the query combination may be changed very quickly by means of a simple reconstruction of the query tree.

If, for instance, the above-mentioned node C1&1980-1984 now contains a number of hits exceeding 20, the node may be divided into two child nodes, C1&1980-1982; C1&1983-1984, and the remaining queries of the query combination may be maintained.

If, on the other hand, the two query nodes C1&1980-1984 and C1&1985-1989 result in a number of hits 6 and 12 respectively, the two nodes should be aggregated into one node, i.e. the parent node, now having 18 hits instead of the original 29 hits. Accordingly, time required for the entity extraction of the site may be reduced.

An example of a way of establishing a robot suitable for information retrieval from the data sources DS1 and DS3 according to the invention will now be described with reference to FIG. 6.

FIGS. 24 a-24 c illustrate access to a data source via a form according to one embodiment of the invention.

The example illustrated below shows a function which may be added to the robot of a data source accessible via a form.

According to the illustrated example, a data source of the nature mentioned above has been accessed. According to the illustrated embodiment, the retrieving profile RP has accessed a data source by means of an input query entry IQE1 via a local query form LQF. The request has resulted in a number of result list entities RLE exceeding the maximum number of the result list MRL.

To reduce the number of hits, a further input query entry IQE1 has been entered in FIG. 6 b in order to narrow the query and to reduce the number of result list entities RLE. Still, the request has resulted in a number of result list entities RLE exceeding the maximum number of the result list MRL.

In FIG. 24 c, the query has been further narrowed and the interval IQE3 has been further reduced. Consequently, the number of result list entities RLE is now less than the maximum number of the result list MRL.

The entities of the result list may now be analyzed and eventually copied to a database and entries corresponding to the obtained result stored in the retrieving profile RP.

Now, the difference between the result list entities RLE obtained in FIG. 6 a and the result list entities RLE obtained in FIG. 24 c is the complementary entries CRL.

This result list is obtained by entering a complementary input query CIQE3 as illustrated in FIG. 6 d. According to the illustrated embodiment, the number of complementary result list entities CRLE is less than the maximum number result list. If not, the system should perform further iterations in order to divide the result list into a number of well-defined result lists.

The manner in which the subdivision of the result lists by performing query iterations as combinations of queries and query intervals in the input form takes place is stored in the retrieving profile RP for later use. Subsequent access to the data source will then be performed in steps according to the stored iteration. If a previous iteration stored in the retrieving profile is no longer effective due to changes in the number and types of entities in the data source, another iteration will be added to the retrieving profile RP in order to extract the desired entities.

An aspect of the invention is to search a number of web sites for a specific type of items, e.g. used cars for sale, at regular time intervals and to save the located information in a well-defined format in a central database. When a customer requests data on items corresponding to a certain set of search criteria, the data will be located in the database.

Each record (item) in the database has the same field, attributes, even though the data in the records may be collected from a number of different web sites. This increases the search opportunities, because the customer will be able to search a number of web sites simultaneously with the same search criteria (a single attribute or a set of attributes) that may not even be available on any of the web sites being searched.

Searching the web sites and saving data at regular time intervals provides an advantage compared with the normal strategy of real-time searching on customer request if one or more of the searched web sites are inaccessible at the time of the request. In the case of real-time searching, no data from the actual web site(s) will be available to the customer, whereas the latest collected data from the given web site(s) will still be available (although they are not brand new) when using a database. If a suitable time interval between searches has been chosen, the contents of the web sites being searched will not change dramatically from one search to the next. 

1. User interface (UI) comprising: an input environment adapted to user inputting of search criteria (SC); said search criteria (SC) defining a search for at least one desired entity; a search engine (SE) adapted to performing a search on at least two different web-based data sources (S1, . . . , Sn); a means for presenting the search result (SR) to the user; said input environment being adapted to user inputting of an order (O), and a business transaction engine (BTE) for initialization of a business transaction (BT) based on at least one user input of an order (O).
 2. The user interface (UI) according to claim 1, wherein said business transaction engine (BTE) comprises means for initialization of said business transaction (BT) on a web-basis.
 3. The user interface (UI) according to claim 1, including a means for establishing a search for a combination of at least two entities, said search engine (SE) being adapted to performing a search on at least two different web-based data sources (S1, . . . Sn) for said combination of entities.
 4. The user interface (UI) according to claim 1, including a means for storing said search criteria (SC) and means for automatically establishing subsequent searches based on the stored search criteria (SC).
 5. The user interface (UI) according to claim 1, including a means for automatically performing a business transaction when entities matching said search criteria (SC) are found.
 6. The user interface (UI) according to claim 1, including a configuration engine (CE), said configuration engine (CE) including a graphical tool for establishing a search for at least one combination (xxxxx, yyyyy) of at least two entities and where said at least one combination may comprise entities found at different data sources (S1-Sn).
 7. The user interface (UI) according to claim 1, wherein said search engine (SE) is adapted to performing a real-time search on the at least two different web-based data sources (S1, . . . , Sn)
 8. The user interface (UI) according to claim 1, wherein said search engine (SE) is adapted to performing a search on the at least two different web-based data sources (S1, . . . , Sn) by means of a central database arrangement (CDA), said database arrangement (CDA) being adapted to storing of entities (E) found during previous searches.
 9. The user interface (UI) according to claim 1, wherein said previous searches are established according to the pre-established trigger conditions.
 10. The user interface (UI) according to claim 1, including a means for establishing a conditional order (OM), said conditional order (O) automatically initiating a business transaction performed by said business transaction engine (BTE), if certain predefined trigger criteria are met.
 11. The user interface (UI) according to claim 1, including a means for establishing a loan offer from at least one loan provider.
 12. The user interface (UI) according to claim 1, wherein said loan offer is established on the basis of at least one user-selected entity.
 13. The user interface (UI) according to claim 1, including a means for accepting a loan offer.
 14. The user interface (UI) according to claim 1, including a means for initiating an order on the basis of the acceptance of a loan offer.
 15. The user interface (UI) according to claim 1, including a means for inputting a set of user-describing data, and wherein the user interface comprises means for submitting a subset of said user describing data to at least one loan provider.
 16. The user interface (UI) according to claim 1, including a shopping cart (SC) adapted to storing possible orders, said shopping cart comprising means for selecting at least one of said stored possible orders, and submitting the(se) selected order(s) to an order manager (OM) with the purpose of initiating an order (O).
 17. The user interface (UI) according to claim 16, wherein said shopping cart (SC) may contain abstract orders (O) which will only be converted into real orders handled by the business transaction engine (BTE) if certain predefined conditions are met.
 18. Method of establishing a transaction configured by at least one set of entities (x,x,x,x,x;y,y,y,y,y), at least two of said entities being accessible via web-servers (S1, . . . Sn), and at least one set of entities comprising at least two entities accessible via different web-servers, the method comprising: establishing at least one query (Qn), said query (Qn) comprising a set of desired entities (x′,x′,x′,x′,x′; y′,y′,y′,y′,y′); searching in at least two of the web-servers (S1, . . . Sn) for entities (x, y) matching the desired entities (x′, y′); and presenting at least one of the found of set entities to a user (U).
 19. Search configuration editor, the editor comprising: a set of user-selectable identifiers, said editor including a means for combining the selected identifiers in suitable way.
 20. The search configuration editor according to claim 19, wherein said identifiers are searchable by means of search engine (SE) associated with the editor.
 21. The search configuration editor according to claim 19, including a means for associating at least one searchable property (71, 72, 73, 74; 79) with at least one identifier.
 22. System adapted to searching for entities contained in web-based data sources (DS), wherein the system comprises: a number of robots established for extraction of data stored in at least two different web-based data sources (DS).
 23. The system adapted to searching for entities contained in web-based data sources (DS) according to claim 23, wherein said robots are adapted to initiating a business transaction upon request by a user (U), said business transactions being performed by means of communication with at least one of the web-based data sources (DS).
 24. System, preferably a web-site, comprising means (SE) for performing a search for entities, the entities including at least one entity-describing parameter, the system comprising: means for facilitating (UI) selection by a user (U) of at least one entity; a means for automatically transferring the at least one entity-describing parameter or at least a subset of parameters to a calculation model; and a means for processing the parameters according to said calculation model and preferably means for displaying the result of the processed parameters to the user (U).
 25. The system according to claim 24, wherein said entities are second-hand items or new items, such as cars.
 26. The system according to claim 24, wherein at least one of said entity-describing parameters is price.
 27. The system according to claim 24, wherein said calculation model is a model for calculation of a loan offer on the basis of at least said price.
 28. The system according to claim 24, wherein said entity-describing parameters are handed over to different calculation models.
 29. The system according to claims 24, wherein calculated loan offers and loan offer conditions are displayed to the user, and wherefrom the user may subsequently select one of the offered loans.
 30. Method of calculating a loan offer intended for financing of specific selected entities, such as cars, boats, computer hardware, etc. by means of a system according to claims 24-30.
 31. System or web-site comprising: means for receiving entity-describing parameters from e.g. another system or another site, means for handing said received entity-describing parameters by at least one calculation model, means for processing said entity-describing parameters according to said calculation model, and preferably means for transferring the result of the processed said entity-describing parameters to a user from the other system or site.
 32. The system or web-site according to claim 31, wherein said calculation model is adapted to calculation of loan offers on the basis of said entity-describing parameters, and any further received parameters.
 33. Communication network-based system for exchanging consumer information between at least one entity provider (SP) and at least one mediator (M), the system comprising: at least one application/order form (OF) comprising at least two associated sets of data (AS1, AS2), at least one of said mediator(S) (M) having facilities for receiving at least two of said associated sets of data (AS1, AS2), a means for transferring at least one of said associated sets of data from the mediator (M) to the entity provider (SP), said system comprising means for requesting at least one further associated set of data (FS) from said mediator (M), said at least one further associated set of data being a subset of said associated sets of data (AS1, AS2), said system comprising means for transferring at least one further associated set (FS) from said mediator (M) to said entity provider (SP) in dependency of said request.
 34. The communication network-based system according to claim 33, wherein said system comprises means for assigning an identifier to said associated sets of data in such a way that the mediator (M) may establish the requested associated set of data on the basis of said request. 